Welcome back @gjeck, this is a great addition!

I'll be off for a few weeks, but I'll be glad to merge your pull request when I'm back.

Quick notes:

I would be glad if the feature would be enabled when possible: custom SQLite, SQLCipher, maybe some versions of macOS, and maybe not all versions of iOS, tvOS, and warchOS. This is not a very fun task, I agree, but it's a habit here.

Also, it looks like the feature does not need to use ColumnDefinition, and that plain Strings would be just enough.

Don't feel compelled to address those points, but they both look like they have to be solved before the changes are shipped on master.

Thank you for the notes @groue! I will make sure to get those changes in.

It looks like custom sqlite is pinned at 3.30.1 so that should be straightforward to support. Do you happen to have an area of the code shedding light on the version requirements of SQLCipher? Apologies, but I am not familiar with this 😅

Sure @gjeck!

Check for example the definition of DatabaseMigrator.registerMigrationWithDeferredForeignKeyCheck(_:). It's a mix of #if and @available checks.

As you see, we can't avoid some duplication of code and documentation. This is real ugly, but this is what we need for our feature :-)

From the failed build on de6f9b7 it looks like SQLCipher version ~3 has issues, while SQLCipher version ~4 seems ok. I'm not sure how to check for the SQLCipher version to account for this.

If there was a way we could expose SQLITE_VERSION_NUMBER then we could maybe not dig into specific SQLCipher versions and just check #if SQLITE_VERSION_NUMBER >= 3025000, but I'm not sure if that's something that is desirable to expose.

SQLCipher tests don't have good Travis logs (I hadn't the opportunity to fix this).

1. Merge or rebase your branch on the development branch: it contains fixes for earlier versions of Xcode.

2. If you want to run SQLCipher tests, go to Tests/CocoaPods/SQLCipher3 or Tests/CocoaPods/SQLCipher4, run pod install in the Terminal, open GRDBTests.xcworkspace, and run tests.

it looks like SQLCipher version ~3 has issues

Indeed SQLCipher 3.4.2 reports... SQLite version 3.24.0:

String.fetchOne(db, sql: "PRAGMA cipher_version") // "3.4.2"
sqlite3_libversion_number()                       // 3024000

The need for distinguishing SQLCipher 3 from SQLCipher 4 has not arisen yet, so we enter uncharted territory :-)

If there was a way we could expose SQLITE_VERSION_NUMBER then we could maybe not dig into specific SQLCipher versions and just check #if SQLITE_VERSION_NUMBER >= 3025000, but I'm not sure if that's something that is desirable to expose.

Swift can't perform such check. There is no C preprocessor :-)

Let's not block this pull request with this problem:

1. I'm OK if the API is available for SQLCipher 3. I expect it will throw an SQL syntax error at runtime. We'll work around this with explicit documentation.
2. Guard your tests with if sqlite3_libversion_number() >= 3025000

In order to reduce code duplication, you can:

#if ...
/// doc...
public func foo(...) { _foo(...) }
#else
/// doc...
@available(...)
public func foo(...) { _foo(...) }
#endif

private func _foo(...) { /* the real job */ }

@groue thank you for all the additional details! I hope I'm not pulling you away from a vacation or anything. d14ac3e should address all comments 🤞. No rush to review/approve 🍹.

Yeah, I'm leaving tomorrow :-) Don't expect any answer until mid February. I'll be happy to catch up then :-)

Sounds great! Enjoy your time off 🌴

Thank you very much @gjeck, this is perfect :-)

Shipped in v4.10.0! Sorry for the delay.